Date: Tue, 21 Sep 93 04:30:02 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #277 

To: packet-radio 


Packet-Radio Digest Tue, 21 Sep 93 Volume 93 : Issue 277 


Today's Topics: 
Connecting Baycom to YEASU 
Digipeaters (one last time) 
duplexer 
Packet to Former Soviet Union??? 
TCP/IP Via digi (NOS) 
Where/How to get IP address? 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Mon, 20 Sep 1993 20:54:57 GMT 

From: dog.ee.lbl.gov!agate! library.ucla.edu!news.ucdavis.edu! jane.ucdavis.edu! 
szhall@network.ucsd.edu 

Subject: Connecting Baycom to YEASU 

To: packet-radio@ucsd.edu 


Right now I am using a Yeasu FT-411 with my Baycom for packet and it works 
great..Someone told me I need to use a 2.2k res. on the PTT and a .1u 
cap.in AFSK of the mic. input. Will this improve my performance even 
better? Right now I am not using a res. or a cap. on my line between the 
BAYCOM and the YEASUE..Is it worth putting these two idems in? tnx for 
answering this..Jeff N6MYF 


Date: 21 Sep 93 02:59:23 GMT 
From: news-mail-gateway@ucsd.edu 


Subject: Digipeaters (one last time) 
To: packet-radio@ucsd.edu 


> From: IN%" grahamwi@cpsc.ucalgary.ca" 18-SEP-1993 18:08:56.24 
> To: IN%"WGOB@delphi. com" 
> Subj: RE: Digipeater 


I appreciate your response, and you (plus a few others) caught me in 
an outright error. I have also figured out how I might better have 
phrased my comments in a couple of other cases. Let's rehash quickly: 


>> If you would substitute "network node" (netrom node) in each ins 
>> where you used "digipeater",... 

> 

> I beg to differ. "A digipeater is a store and forward relay node" 
> is an perfectly accurate description.... 


I describe how a digipeater holds data as "buffering". True store-and- 
forward is a process wherein the data is available for retransmission 
until it is successfully passed or the link shuts down. What is 

meant by buffering is that the frame is output from the buffer one time 
and then is lost. Error recovery in this case requires refilling the 
buffer. 


>> Digipeating is an instantaneous retransmission mode available 
>> (unfortunately) as a "feature" on virtually all TNCs. 


Not so. To digipeat a packet, a TNC must receive the entire 
original packet, store it, change one bit in the address header (to 
indicate that it has repeated it), then forward it by 
re-transmitting it. 


VV VV WV 


What you say is true. What I meant by instantaneous is that the frame 
is retransmitted immediately without regard (or knowledge) of the 
status of the next station in the path. 


>> Digipeaters do xNOTx store and forward; 

> 

> Yes, they do, although not at the same level of the AX.25 protocol 
> as a netrom node does. 


See above. 
>> they do xNOTx test the frequency prior to transmitting; 
The TNC uses the same timing parameters to re-transmit a digipeated 


> 
> 
> packet as for its own packets, except that DWAIT is ignored. DWAIT 
> exists to allow digipeated packets to have priority on the channel, 


> but the TNC still won't key the radio for the digpeated packet if 
> the channel is busy. 


THIS is the error I mentioned at the top. What I should have said is 


"Digipeaters transmit immediately on a clear channel without regard for 
the presence of other stations." 


However, DWAIT is only used by the originating station and not by any 
of the digipeaters. Neither do the digipeaters use other channel 
"optimizing" parms like Persistence and Slottime or the older algorithm 
which multiplied TXD by a randomly selected integer in the range 0-15. 
My argument against digipeating on all but the most sparsely 

populated of channels is that the digipeaters tend to hog the frequency 
by virtue of their priority behavior. 


>> and only at the destination station is the packet frame tested f£ 


Well, maybe, I don't know. A digipeater doesn't wait for an ACK 
packet when digipeating, but what it does with a packet with a bad 
checksum probably depends on whether PASSALL is set ON or OFF. 
Digipeating is an unconnected mode. 


VVVV WV 


I should have said: 
"Only at the destination station is the frame tested and an ACK sent 
back over the same path to the originating station." 


To the best of my knowledge, PASSALL has no effect when digipeating. 
Otherwise, the problem of interference (collisions) would be compounded 
by the additional "trashed" packets being forwarded which would still 
be rejected at the destination. 


There are some repeaters which operate like a voice repeater: they 
receive bits on one frequency, recover the digital data, then 
regenerate the bits and retransmit on another frequency with only 
one bit time or so of delay. Perhaps you are thinking of one of 
these repeaters. 


VVVNV Vv 


I wasn't. 


> We don't call them digipeaters here; we call 
> them digital regenerating repeaters (or something similar), to 
> avoid confusion. 


Which brings us back to the point where this thread began. I suspect 
that on several occasions your local operators have referred to the 
"digital regenerating repeaters" (a real mouthful) as "digipeaters". 


What I tried to say then, and repeat now, is that careless use of the 
terminology (jargon) is very confusing to newcomers (and old timers, 
too) and we should use caution to ensure consistency of understanding. 


My error in judgement was allowing my personal bias against digipeating 
as a common practice set such a strident tone to my statements. 
For example: 


>> Digipeating, as a mod supported by most 
>> netrom compatible nodes. Fortunately, it can also be disabled, 
>> should be in virtually all cases. 


> Digipeating is useful when a station can't hit the local netrom 
> node. 


I still read my last statement above to be that network nodes should 

not be used to digipeat. If someone has to digipeat to uplink to a node 
(a common theme in the responses) and be able to then use the network, 
that is another matter. 


Finally, because I didn't grow the tree, I'm just sawing the limb: 


Date: 20 Sep 1993 14:23:47 GMT 

From: pipex!zaphod.crihan.fr!vishnu.jussieu.fr!masi!darche@uunet.uu.net 
Subject: duplexer 

To: packet-radio@ucsd.edu 


I'm desiging a wireless network for little mobile robots. It's a full-duplex 
communication. The name of my system is ActNet for robotic Actors Network. 


Bibliography : 

[Darche - Nowak 93] Ph. Darche, G. Nowak - "ActNet : A Heterogeneous Network of 
Actors for Learning of Parallelism, Communication and Synchronization" 

- NATO Series F : Computer and Systems Sciences - Springer Verlag - Liege 

- Novembre 1992 paru aussi en rapport de recherche MASI N! 93-22 

- Universie Pierre et Marie Curie - Paris. 


I have to design a duplexer and I would like to know the way to specify this one 
(attenuation and duplex spacing in particulary) from the features of the emitter 
(emitting frequency coverage and emission power mainly) and of the receiver 
(sensitivity and receiving frequency coverage mainly). 


Specifications of the transmitter : 


- FM modulation, 

- transmitter power Po = 1 Watts maximum 

- transmitter frequency coverage fo = (40-45 Mhz) and (70-75Mhz), 
- output impedance Zo = 50 ohms, 


Specifications of the receiver : 

- FM modulation, 

- reception frequency fr = (40-45 Mhz) and (70-75Mhz), 
- input impedance Zi = 50 ohms, 

- reception IC : Motorola MC3362-3363. 

Channel spacing : 50 Khz. 

Could you help me ? 


Thanks in advance and best regards. 


NVI ie 
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Universite Paris VI 
Institut Blaise Pascal 
Laboratoire MASI 

M. Darche Philippe 

couloir 65/66 - bureau 206 
4, Place Jussieu 

75252 Paris cedex 05 


FRANCE 

Email : darche@masi.ibp.fr | 

Telephone : 33-1-44-27-34-23 | "excuse for my french english !" 
Fax : 33-1-44-27-62-86 | me. 


Date: 20 Sep 93 18:53:12 GMT 

From: ogicse!uwm.edu!math.ohio-state.edu!usc!nic.csu.net!eis.CalState.EDU! 
sadams@network.ucsd.edu 

Subject: Packet to Former Soviet Union??? 

To: packet-radio@ucsd.edu 


Is it possible to send a packet message into the x-Soviet Union? 
Do they have packet radio there?? 


Steve Adams 

internet - sadams@eis.calstate.edu 

HAM - KD6KGJ 

Packet - KD6KGI@n6qmy .4#nocal.ca.usa.na 


Date: Mon, 20 Sep 1993 11:48:02 GMT 

From: library.ucla.edu!europa.eng.gtefsd.com!howland.reston.ans.net! 
vixen.cso.uiuc.edu!moe.ksu.ksu.edu! cherokee.nsuok.edu! black@network.ucsd.edu 
Subject: TCP/IP Via digi (NOS) 

To: packet-radio@ucsd.edu 


Is it possible to set up a digipeater to be used when telnetting? 
(Even if the digipeater is not TCP/IP? (Netrom). 


Thanks, 


Steve Black (KC5BAU) 
black@cherokee.nsuok. edu 


- N N sssS U U - 
- NN N S S U U Northeastern State University 
- N N N S U U Tahlequah, Oklahoma - 


Date: Mon, 20 Sep 1993 11:50:50 GMT 

From: usc!howland.reston.ans.net!vixen.cso.uiuc.edu!moe.ksu.ksu.edu! 
cherokee.nsuok. edu! black@network.ucsd.edu 

Subject: Where/How to get IP address? 

To: packet-radio@ucsd.edu 


I was wondering who I need to contact to get an IP address so that I 
can run NOS with a real IP address? The docs say talk to other local TCP/IP 
users, but I don't know any. Anu help would be much appreciated. 


Thanks, 


Steve Black (KC5BAU) 
black@cherokee.nsuok. edu 


- N N ssssS U U : 
- NN N S S U U Northeastern State University 
- N N N S U U Tahlequah, Oklahoma - 


End of Packet-Radio Digest V93 #277 
KAKKKKKKKKKKKKKKKKKKKKEKKEKR KAKA 


